As it is generally known, computer system users must login to use many application programs or services, typically by entering login information including a user name and password. While users may often need to access multiple programs, it is inconvenient and undesirable for them to have to enter login information more than once. In some existing systems, administrators for Web application programs can configure a Single Sign-On (SSO) environment including multiple applications located on different machines. In these systems, a user logs in once with their user name and password, and is then granted access to the multiple applications contained in the SSO environment. Specifically, when the user's Web browser program accesses an SSO application through its URL (Uniform Resource Locator), they are prompted to login with a user name and password. After the user is authenticated, the application sends a Web page via HTTP (HyperText Transport Protocol) to be displayed by the user's Web browser, as well as a Web cookie containing the user name provided by the user when logging in. The user's Web browser program receives and displays the Web page, and stores the Web cookie on the user's computer system. This stored SSO Web cookie is thereafter used to demonstrate that the user has previously been authenticated. Conventional Web browser operation enables the stored SSO Web cookie to be sent along with subsequent outgoing HTTP requests to Web applications. When an SSO application receives an HTTP request and finds an SSO Web cookie included in the request, the application can accept the SSO Web cookie as proof of the user's previous authentication. Accordingly, the receiving application need not re-prompt the user for a password. The SSO Web cookie in existing systems includes a single user identifier, usually consisting of a distinguished user name for the SSO environment. The receiving application sees the user name in the cookie, and provides access for the user associated with the user name as if they had logged in directly and expressly provided a password.
While these existing systems are useful when a single user information directory is shared across all applications in the SSO environment, they are inadequate in complex SSO configurations in which a user is known by many user names. For example, some existing SSO products, such as Oracle9iAS Single Sign-On provided by Oracle Corporation, expect that applications in the SSO environment share a common user information directory, so that a user effectively has only one distinguished user name in the SSO environment. However, customers must sometimes merge diverse systems into a single SSO environment, in situations where applications have already been deployed with their own user information directories, and potentially their own protocols or formats for naming users. Accordingly, customers may require support for multiple, different user information directories, and need to allow users to have and use multiple identities (i.e. multiple names).
For example, a user may be primarily known in one user information directory by the LDAP format user name “uid=jdoe,cn=users,dc=myorg,dc=com”. In another, separate user information directory, the same user may be known by a different name, such as “John M Doe/MyCompany”. When a user has multiple names, the existing systems described above are not sufficient to provide effective SSO operation. When the SSO Web cookie is received, the receiving application relies on the user name information within the SSO Web cookie to determine the identity of the user that has been previously authenticated. SSO functionality in these existing systems breaks down if an application receives an SSO Web cookie with a form of user name that it cannot recognize. For example, if an application receives an SSO cookie with the user name “John M Doe/MyCompany”, successful SSO operation depends on whether this specific user name can be recognized by the receiving application. SSO support fails if, for example, the receiving application is only equipped to recognize an alternate form of the user's name, such as “uid=jdoe,cn=users,dc=myorg,dc=com”.
While it might be possible to embed multiple user names into an SSO Web cookie, such an approach would require applications to agree upon a standard format to represent a user name list, as well as a method for interpreting name lists. While it might be desirable for all applications in an SSO environment to converge to a common strategy for processing a list of names, and/or for recognizing any of a user's multiple names, this is difficult to accomplish across multiple products.
Every application in the SSO environment may be capable of creating an SSO Web cookie for a user when they log in with their user name and password. In existing systems, there is currently no way for an administrator to configure the user name that should appear within an SSO Web cookie for a given user. It would be desirable to have a new system that allows an SSO application to use a name that renders the SSO Web cookie valid not only for the current application, but also has the greatest likelihood to be recognized and validated by other applications in the SSO environment.
Existing products providing identity management and SSO functionality employ different tactics for dealing with multiple user information directories and user names. Some providers allow multiple user information directories, and allow rules to be specified for finding a user among the multiple user information directories. An example of this approach is found in the RadiantOne™ product of Radiant Logic, Inc. However, these existing systems ultimately resolve to one source of identity information for the user. In Netegrity® SiteMinder systems, provided by Netegrity, Inc., a user name is associated with a user profile which is unique in the SSO environment, thus requiring user information to be centrally defined. Given organizational and practical deployment issues for merging together disparate systems into a single SSO environment, requiring one centralized source of user information is not always feasible.
Some existing products for dealing with additional user identities provide a software plug-in architecture. Using this approach, an application can pass off user name mapping responsibility to a software plug-in. An example of this type of approach is found in the Lotus Domino HTTP server system provided by IBM/®. During operation, the plug-in may be passed a foreign user name and password, verify the user's information against a custom directory, and then transform the foreign user name into an identity that is recognizable and usable by the application. The plug-in returns a user name to the application by which to identify the user, and this returned user name is the name that the user is known by the application while they are using the application, and is thus the user's “effective name” for that application. The application places the effective name for that application into the SSO Web cookie. Accordingly, if a plug-in authenticates the user “uid=jdoe,cn=users,dc=myorg,dc=com”, the plug-in may tell the application that the user's name has been mapped to the effective name “John M Doe/MyCompany”. In this way, the user name returned by the plug-in is the user's name both for operating the application, and for placing into any SSO Web cookie. Thus there is no means for the plug-in to say that the name in the SSO Web cookie should be something other than “John M Doe/MyCompany”. In these existing systems, the user name put into an SSO Web cookie must reflect the effective user identity currently operating in the current application environment. Plug-ins therefore do not provide any ability to specify an alternative user name to that understood and used by the current application.
Another possible method for dealing with additional user identities in an SSO environment is a completely custom solution, expanding on a plug-in type architecture. A plug-in can control the user name to be placed into an SSO Web cookie by the plug-in itself taking all responsibility for the SSO Web cookie, including its creation. This approach would require that each application allow delegation of SSO Web cookie responsibility to the plug-in, and likely require the application to provide extensive APIs (Application Programming Interfaces) for the necessary customization. The system or network administrator would have to provide and deploy the custom plug-in code. Such customized solutions are not desirable, because they are invariably expensive to create and support. Moreover, the problem of determining what name to place into an SSO cookie would still not be solved, but rather just passed on to the customization code, and there is no obvious way to deal with the multiple names problem there.
For the reasons above and others, it would be desirable to have a new system for providing an SSO environment, that is capable of supporting multiple user information directories, that allows users to have multiple user identifiers in different formats, and that does not require extensive customization of applications in the SSO environment to allow external handling of foreign user identifiers.